GSoC’22 @GNOME - Coding Phase 1: Evaluate✅, Design✒️, <Code/>

Pooja Patel
4 min readJul 15, 2022

--

Updates of the first two weeks of my GSoC Journey with GNOME

Takeaways

  1. Communicate effectively and cohesively with mentors
  2. Plan your time and set deadlines for yourself
  3. Aim for iteration, not perfection

A short project brief

GNOME HIG CSS Library project aims to design, develop and publish a unified CSS library incorporating the revised Human Interface and Visual Identity Guidelines allowing developers to update the existing GNOME websites and create new ones with a congruent visual identity.

Check out my first blog to know more about the GSoC program, GNOME and my summer project.

A deeper look into the project

To ensure that the overall consistency is maintained, I worked on updating the colors and typography - fonts, font size, font weight, etc. to follow the GNOME HIG Guidelines before starting to code.

Here’s an image of the colors defined earlier in the project, in the HIG reference, assumed colors for adding to the range of available colors, and the final list of colors.

To view the complete color list - go here.

Law of Similarity

Color, shape, and size, orientation, and movement can signal that elements belong to the same group and likely share a common meaning or functionality.

One of the significant steps in the project is to analyze the design and use-case of the existing elements and components before starting with their development. This gives a detailed overview of the currently used designs.

I started out with the inventory of the paragraph <p>, lists <ol><ul><li>, links<a> and components like header, and footer.

Errors often have simple yet unexpected solutions

Solutions can be found, even to the darkest of problems, if one only remembers to ask their mentors ~ Pooja Patel😂

This is a story about my trials and tribulations with probably the funniest errors ever - 418. I’m a teapot (yeah, I was just as confused and amused as you are).

Before starting with coding I re-cloned the framework and created a new fork to start with a clean slate. After finishing work on the colors and typography issue I tried to push the code on my fork to create a merge(pull) request. But I repeatedly encountered an error “:fatal: unable to access: The requested URL returned error: 418”⚠️

In trying to figure out more about the error, I realized it was just a joke. So well the story begins in 1998 at Xerox’s famous PARC research center in Palo Alto, where Larry Masinter’s duties included working on Web and Internet standards. He proposed a new error code called 418 stating quite cheekily “there is a strong, dark, rich requirement for a protocol designed expressly for the brewing of coffee” and that the hypertext transfer protocol, HTTP, should now be joined by HTCPC — the Hyper Text Coffee Pot Control Protocol, “for controlling, monitoring, and diagnosing coffee pots.” According to Masinter’s proposal, servers would now also begin recognizing “coffee:” alongside “http:” with a security consideration that “anyone who gets in between me and my morning coffee should be insecure.” It warns users of the possibility of “denial of coffee service” attacks.

The reason behind this joke is that every year on April 1st the IETF publishes a humorous specification to mark April Fool’s Day. So basically 418 is a joke code. Other such joke codes are the “HTJP, the Hypertext Jeopardy Protocol”🤣 introduced in 2019, and “Scenic Routing for IPv6” introduced in 2016(the complete list can be found here and it’s worth a read🤣). The documentation mentions that this should not be implemented in server software, though it has been supported across multiple platforms as a sort of hidden easter egg.

I was happy I stumbled upon an easter egg but I had no idea how to solve it as the documentation was super unhelpful(but funny). So for the next three days, I scoured the Mozilla MDN docs, StackOverflow, Github, StackExchange, and a whole lot of other forums. I tried all the suggestions and possible solutions, some of which included:

  1. Creating and using personal and project tokens,
  2. Re-configuring remote keys, config file,
  3. Re-cloning and setting up the project again,
  4. Setting up and updating remotes to even include my username, password,
  5. Re-installing git, vscode, and
  6. Restarting my laptop a million times!!

I realized I was fighting a losing battle and finally decided to ask my mentor what the issue was. I sent a detailed log of the error and all the possible solutions I tried. My mentor looked at the error logs and within a minute asked me to check if my remotes configured for the project used ssh as GNOME did not support HTTPS requests for pushing code to repositories. I changed my remotes using two simple commands and to my great surprise (and dismay) I could push my commits.

Note to self - talk to your mentor if you are stuck with an issue for more than a day.

Please comment and leave a clap if you liked the article. Thank you soo much for giving it a read, have an amazing day!!

Project Repo | LinkedIn

--

--

Pooja Patel

Google Summer of Code’22 @ GNOME | UX Designer | Front-End Developer